There are multiple situations where an employee of a first company needs access to sites or systems belonging to a second company. For example, the first company may be a vendor that sells and/or services a product (e.g., a data storage device or other storage resource), and the second company may be a customer of the first company that purchases and uses that product at one of its facilities (e.g., a data center). While a vendor servicing a product owned by a customer is one common such example, other situations may include attending meetings at a secure customer facility, attending a conference call where only certified participants should attend, and the like. In each case, it is typically necessary or desired for the individual from the first company to be authenticated or authorized by the second company.
Today such situations are often resolved in a manner that either relies on physical security tokens carried by the individual which can be faked, stolen, or forged, or relies on a trusted, personal relationship between parties such that the parties recognize each other or each other's voices.
For service situations especially, these issues are further compounded as service access typically requires an elevated/privileged level of access to assets in the customer's environment (e.g., data center). This access to machines (e.g., computing and/or storage devices) is dependent on knowing a set of credentials, often set by the company creating the product (e.g., where the product is the machine or the product runs on the machine), and are typically uniform across all instances of the product at a certain revision. Using these well-known credentials and a stale or faked physical access mechanism, a service engineer can compromise multiple product instances.